The present invention relates generally to computer software and more specifically to a processing method which improves the functionality of job-step charge-back systems, by enabling and providing a more accurate charge-back based on cognizance of software products being used.
Much of the software in use by corporations, organizations and individuals is licensed either directly or indirectly from a variety of software vendors. The rights granted the licensees may take a variety of forms. For example, a software product might be licensed to an organization for unlimited use, on any number of computers, but only within that organization. Or, the organization might be permitted to only use the software on certain computers, or may only be permitted to allow its use by certain named employees, or by only a specified maximum number of concurrent employees, or until a specified date, or only on certain days of the week, or based on any other set of restrictions that the vendor may negotiate with the organization.
In many cases, vendors have incorporated protective mechanisms (PMs) into their software products to try and determine whether the usage restrictions that are embodied in the license terms are ever violated in practice. For example, such a PM, which is typically invoked when the associated software product is initiated, might determine whether the computer (as identified by such things as a serial number or other unique characteristic) that the software is operating on is on the list of computers that the software is licensed to. Or, the PM might count the number of users concurrently using the software, checking to see whether a licensed maximum is ever exceeded.
If the PM detects attempted violations, a variety of actions may be taken, from issuing a warning while allowing execution, to preventing the software from operating. Typically, the PM also keeps a log of all such violation attempts.
For the PM to be able to match the actual use of a software product to the organization's licensed rights, the PM must know what those rights are. These are often embodied in a license certificate or via an encrypted password which the software vendor gives to the organization, which in turn supplies it to the PM. Typically, a PM will not allow the software product to operate at all if a certificate is not supplied, missing, expired, or otherwise not made “known” to the PM.
While many vendors have developed their own PM, some use general purpose software supplied to them by other vendors. Such general PM facilities are known as License Managers (LMs), and are available from a variety of vendors, including Isogon (LicensePower/iFOR), Globetrotter (FLEXlm), IBM (LUM), and Rainbow (SentinelLM). As with PMs written by the product vendors themselves, LMs from different vendors use certificates in different forms and administer them in different ways.
In March of 1999, an IT industry standard for LMs was approved by The Open Group. Known as XSLM, the standard is expected to encourage the development of XSLM-compliant LMs from several LM vendors. In particular, Isogon Corporation and IBM are jointly developing an XSLM-compliant LM that may be marketed by each of the parties under their respective brands.
A major function of an XSLM-compliant licensing system is to collect and record data about the usage of the licensed products and relevant events related to license management for a heterogeneous system of computer systems. An XSLM-compliant system is generally composed of a server that operates on one or more of the computers within the network of computers and “agent” software that operates on each or selected ones of the individual computers (and individual LPARs) within the network, communicating with the server and enforcing the licensing policies. Agent software is developed for the operating system and computer system upon which it executes, and in some instances, the agent software is incorporated directly into the server. Accordingly, a single XSLM-compliant system can collect and record data about multiple operating systems, computer hardware configurations, and a diverse set of licensed software products.
A compliant XSLM system (hereinafter referred to as XSLM) maintains, in a database and/or log files, three types of information: certificate data, status data, and historical data.
Certificate data is the combination of information embodied in the license certificate initially provided by the software vendor; information provided by the customer's license administrator to complement or override, when allowed, the licensing policy specified in the license certificate; and, in some instances, information created and maintained by the XSLM.
Status data is collected by the licensing system while it is running. At prescribed points in time, it provides information about the licenses presently in use and the value of various meters maintained by the licensing system. Some applications can be licensed based on the count of some units whose meaning in general is known only to the application, and the licensing system keeps track of the units to be counted, acting as a “record keeper.” The updating of the meter is explicitly requested by the application with an API call or is automatically performed by another process. A change in the status information is also triggered by events external to the licensing system, such as the request for a new license, a change in policy setting (e.g. the administrator switching from soft stop to hard stop) the expiration of a timer, or a change in the computing environment (e.g., the MIPS capacity of a partition is changed, a processor added, parameters or data affecting computing operations, etc.).
Historical data is the persistent log of events relevant to license management. All or selected events related to license administration actions are logged to form an audit trail (e.g. the addition or deletion of a certificate to/from the license database). The logging of events related to license usage (e.g. an application requesting or releasing a license, or a meter being updated) is usually either under the administrator's control or specified by rules in the license certificate.
Computer software products execute under the control of a particular instance of an operating system. The operating system may control an entire single physical computer; a complex or Sysplex of closely-coupled computers; a network of computers; or only a subdivision or partition of a single physical computer; with other operating system instances controlling other partitions.
For example, the operation of a desktop PC may be entirely controlled by Windows 98, or the PC may be partitioned so as to selectively (though not concurrently) be controlled by Windows 2000, Linux, or some other operating system. On other computers, such as the S/390 mainframe, multiple logical partitions (LPAR) can be established in which separate operating systems may operate concurrently. Each operating system instance, whether controlling an entire computer, a partition of a computer, a complex of computers, or network of computers, is referred to as a Logical Operating System (LOS).
The XSLM is responsible for controlling the licensed software products that execute under the LOS, ensuring that the software is used by valid, authorized customers, in accordance with licensed rights. Software products, instrumented to do so, accomplish this by engaging in a licensing session consisting of a prescribed dialog of function calls with the XSLM.
The license session typically begins when the product performs a “Get-License” function call [xslm—basic—request—license( ) or xslm—adv—request—license( )] to the XSLM in order to determine whether the product has permission to execute further. If a certificate exists, and meets the circumstances of the product's proposed execution (e.g., a valid user-id, and/or computer serial number, or LOS id, or other license terms and conditions) the product receives an “okay-to-process” return code from the Get-License request. In the simplest case, the license session ends when the product issues the “Release-License” function call [xslm—basic—release—license( ) or xslm—adv—release—license( )] to indicate that the product's operation is complete. There may also be intervening function-calls within the license session to update status and historical data or to perform other XSLM functions.
In order to associate all function calls of a license session with one another, and to recognize that all are part of the same session, the XSLM assigns a “License-Handle” (a unique code-value) to the session, and returns it to the software product as part of the information returned by Get-License. The software product must then supply the same License-Handle as part of each subsequent function call within the session. As a convenience to the requesting program, the XSLM permits it to specify a “token” (in many API function calls) that is further associated with the licensing session. If the value of the token was not set to zero, the licensing system signs all the data transmitted in the API call (i.e., all the input parameters as received by the application and all the output parameters just computed) using the private key of the licensing system publisher.
Typically, subject to the preferences of the customer, the XSLM will record or log certain information about each function call. For example, recorded information applicable to Get-License requests might include the time the request was made; the value of the License-Handle applicable to the dialog of which the Get-License is part; the software product making the request; the LOS-id; the user-id of the user executing the product; and whether the request was granted or denied. This information is potentially of great use and interest to those who wish to know what software products are in use within their organization, how often they're used, whether any attempts at use were beyond licensed limits and thus denied, and so forth.
On most computer systems, a variety of information about the particular program-processes (for example, the job or job-step on the OS/390 mainframe) that execute on each LOS is also captured and recorded or logged (independently of whether the program uses XSLM or not), either by the LOS itself or by other software facilities operating on the system. Process-related information may include the job-name; the job-id; the LOS-id; “accounting” information applicable to the job; the job-step-id; the processing-program name; the amount of CPU-time consumed by the process; the libraries, files or databases used by the process; the number of input or output operations performed; etc. For example, in the OS/390 mainframe environment, much of this process-related information is gathered by the LOS or by its components and recorded in the System Management Facility (SMF) data file.
As an example of process-related information gathered by other software facilities, SoftAudit, a product of Isogon Corporation, captures information about each module used by a job or job-step and records this and additional information to its own log-file. Certain SoftAudit features are described in U.S. Pat. No. 5,590,056, the contents of which are incorporated by reference herein. Similarly, optimization and tuning products, such as InTune from BMC or Strobe from Compuware, capture information related to the efficiency of the process and record this information in their own log files. But, as an alternative, some products of this sort record their information in the OS/390 SMF data-file, using system facilities that permit data to be written to this data-file as special records, or to other system logs. This is done as a convenience, so that the end-user need not deal with a multitude of data files containing diverse data.
Though the XSLM may potentially gather a great deal of data related to the use of licensed software, it is not concerned with determining the particular program-process that might be using the software in a particular instance, or other process-related information, since this information is generally not relevant to issues of enforcing the licensing and licensed rights of the licensor of the licensed software.
In fact, the XSLM standard does not contain, as either a requirement or an option, specifications for determining or recording process identity or process-related information.
Furthermore, there is not a one-to-one correspondence of licensing sessions to executing processes. For example, on OS/390 a particular job or job-step might utilize a single licensed product, multiple licensed products, or no licensed products (in which latter case no licensing sessions would result). In the case of multiple licensed products used within a single process, the associated sessions might occur serially (if the licensed products were used seriatum) or might be interlinked, or nested, if use of a second product was begun before use of the first product was completed. Moreover, multiple successive uses of even a single product would also result in multiple sessions.
Note also that the type of licensing information such as the XSLM gathers and records in a log may also be gathered by other software programs, for example by utilizing an Application Programming Interface (API) that may be provided by the XSLM, or exits which may be provided by the XSLM, or by intercepting the invocations of the XSLM function-calls themselves. This licensing information, as with the licensing information gathered by the XSLM itself, is not correlated to the process it pertains to.
But while process-related information is not needed to enforce licensed rights and license management, and an XSLM-compliant LM provides no means of correlating licensing information relating to, and logged by, the XSLM (or by other programs) with process-data, if these two types of data were correlated, it would be quite valuable to many software asset managers, contracts officers, and system programmers.
Software inventory and usage-monitoring products, such as SoftAudit, correlate the module-name and process-identity or job-number information that they gather, as described above, to the associated product that is being executed. But this information is not further correlated with XSLM licensing information.